• Implement license resolution from manifest and LICENSE files
• Add license compatibility checking for dependencies in component analysis
• Create new CLI command for project license information retrieval
• Include project license in generated SBOM root component
• Refactor header constants to tools module for reusability

Main license check orchestration module

src/license/index.js

Project license resolution from manifest and files

src/license/project_license.js

Backend license analysis API client integration

src/license/licenses_api.js

Description

The SBOM generator always serializes provided license strings into CycloneDX licenses[].license.id
even when the value may be a non-SPDX name/expression (e.g., Maven ...). This can make project
license information unusable/unparseable for backend ingestion.

Code

src/cyclone_dx_sbom.js[R46-55]

+	// Add licenses if provided (CycloneDX format)
+	if (licenses) {
+		const licenseArray = Array.isArray(licenses) ? licenses : [licenses];
+		componentObject.licenses = licenseArray.map(lic => {
+			if (typeof lic === 'string') {
+				// If it's a string, treat it as an SPDX id or name
+				return { license: { id: lic } };
+			}
+			return lic;
+		});

Evidence

PR Compliance ID 1 requires the SBOM to include project license information in an
ingestible/parseable way. The new logic unconditionally writes any string as license.id, which is
intended for SPDX identifiers; non-SPDX values will likely be mis-parsed or rejected by downstream
tooling.

SBOM includes project-level license information
src/cyclone_dx_sbom.js[46-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The SBOM currently writes any license string into CycloneDX `licenses[].license.id`, which should be reserved for SPDX license IDs. When the manifest provides a license name (common in Maven) or a sentinel like `SEE LICENSE IN FILE`, the SBOM will carry an invalid `id`, risking backend ingestion/parsing failures.
## Issue Context
Project license strings come from multiple ecosystems and may not be SPDX-normalized. CycloneDX supports both `license.id` (SPDX) and `license.name` (free-form), plus `expression`.
## Fix Focus Areas
- src/cyclone_dx_sbom.js[46-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

identifyLicenseViaBackend() calls getTokenHeaders() but src/license/project_license.js never imports
it, so backend identification always falls back to local detection (and won’t send auth headers even
when configured). This makes backend-based LICENSE identification effectively non-functional and
silently reduces accuracy.

Code

src/license/project_license.js[R145-156]

+export async function identifyLicenseViaBackend(licenseFilePath, backendUrl, opts = {}) {
+	try {
+		const fileContent = fs.readFileSync(licenseFilePath);
+		const url = `${backendUrl.replace(/\/$/, '')}/licenses/identify`;
+		const tokenHeaders = getTokenHeaders(opts);
+		const fetchOptions = {
+			method: 'POST',
+			headers: {
+				'Content-Type': 'application/octet-stream',
+				...tokenHeaders,
+			},
+			body: fileContent,

Evidence

project_license.js references getTokenHeaders() without importing it, so the call will throw and be
caught by the surrounding try/catch, returning null and preventing backend identification from ever
succeeding.

src/license/project_license.js[9-12]
src/license/project_license.js[145-155]
src/tools.js[175-203]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`identifyLicenseViaBackend()` references `getTokenHeaders()` but `src/license/project_license.js` does not import it. This causes backend license identification to always fail and fall back to local detection.
### Issue Context
`getTokenHeaders` was moved to `src/tools.js` and is used elsewhere (e.g., `src/license/licenses_api.js`, `src/analysis.js`). This function should also be used for `/licenses/identify` calls.
### Fix Focus Areas
- src/license/project_license.js[9-12]
- src/license/project_license.js[145-156]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

getCompatibility() returns 'incompatible' for STRONG_COPYLEFT dependencies even when projectLicense
is null, causing runLicenseCheck() to report incompatibleDependencies with no project license
baseline. This produces incorrect compliance output (false positives) whenever the project license
can’t be resolved.

Code

src/license/compatibility.js[R15-25]

+export function getCompatibility(projectLicense, dependencyLicenses, dependencyCategory) {
+	if (!projectLicense && !dependencyLicenses?.length) return 'unknown';
+
+	// Use backend category when available (from API v5 licenses / analysis report)
+	const cat = String(dependencyCategory || '').toUpperCase();
+	if (cat === 'STRONG_COPYLEFT') {
+		const proj = projectLicense ? normalize(projectLicense) : '';
+		if (isPermissive(proj)) return 'incompatible';
+		if (isCopyleft(proj)) return 'unknown';
+		return 'incompatible';
+	}

Evidence

When dependencyCategory is STRONG_COPYLEFT and projectLicense is falsy, getCompatibility()
normalizes it to an empty string and returns 'incompatible'. runLicenseCheck() may pass a null
project license and will record incompatibilities based on that return value.

src/license/compatibility.js[15-25]
src/license/index.js[99-114]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getCompatibility()` can return `'incompatible'` even when `projectLicense` is missing. This leads `runLicenseCheck()` to emit `incompatibleDependencies` without a known project license baseline.
### Issue Context
`runLicenseCheck()` explicitly sets `projectLicenseForCheck` to `null` when neither manifest nor LICENSE file yields a license.
### Fix Focus Areas
- src/license/compatibility.js[15-33]
- src/license/index.js[99-114]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools